src/hooks/useRemoteConnection.ts (1)

21-28: Heartbeat fires immediately after reconnect — consider a brief delay.

When the WebSocket reconnects (after the 3s reconnect timeout), the first heartbeat ping fires immediately in onopen, then every 3 seconds via setInterval. This is fine functionally, but if you want the first latency reading sooner after connect, you could send an initial ping immediately in onopen before starting the interval.

This is a minor UX observation — the first latency display won't appear until up to 3 seconds after connection.

Optional: send initial ping immediately

 socket.onopen = () => {
     setStatus('connected');
+    // Send first ping immediately for quick latency reading
+    socket.send(JSON.stringify({ type: 'ping', timestamp: Date.now() }));
     heartbeatTimer = setInterval(() => {
         if (socket.readyState === WebSocket.OPEN) {
             socket.send(JSON.stringify({ type: 'ping', timestamp: Date.now() }));
         }
     }, 3000);
 };

src/components/Trackpad/ControlBar.tsx (1)

80-97: Non-functional Copy/Paste buttons and commented-out L-Click code.

The Copy and Paste buttons (lines 80–89) have no event handlers — they render but do nothing on interaction. The L-Click button (lines 90–97) is fully commented out. If these are WIP placeholders, consider removing them from this PR to keep the diff focused on the latency feature, or add TODO comments indicating they're planned.

src/hooks/useRemoteConnection.ts (1)

31-41: RTT calculation assumes msg.timestamp is echoed back as a number.

If the server-side handler ever coerces the timestamp to a string (e.g., via JSON key handling), Date.now() - msg.timestamp would still work due to JS implicit coercion, but a negative or nonsensical RTT could surface if the field is missing or malformed. Consider a guard:

 if (msg.type === 'pong') {
-    const rtt = Date.now() - msg.timestamp;
-    setLatency(rtt);
+    const rtt = Date.now() - msg.timestamp;
+    if (Number.isFinite(rtt) && rtt >= 0) {
+        setLatency(rtt);
+    }
 }

src/hooks/useRemoteConnection.ts (2)

58-65: Consider exponential backoff for reconnection.

The fixed 3-second reconnect delay (Line 64) could produce rapid repeated connection attempts if the server is down for an extended period. For a LAN-only tool this is low-risk, but an exponential backoff (e.g., 1s → 2s → 4s → capped at 30s) would be more resilient.

---

91-95: Consider typing msg parameter instead of any.

send accepts any, which bypasses type safety. Since the hook is used to send known message shapes (InputMessage, ping, etc.), a union type or generic would catch misuse at compile time.

src/hooks/useRemoteConnection.ts (2)

36-45: Consider clearing heartbeatTimer before starting a new interval.

If onopen were ever invoked more than once for the same socket (unlikely but possible with some runtimes), the previous interval would leak. A defensive clearInterval costs nothing.

Proposed fix

 socket.onopen = () => {
     if (!isMounted) return;
     setStatus("connected");
     reconnectDelay = 1000;
+    clearInterval(heartbeatTimer);
     heartbeatTimer = setInterval(() => {

---

23-29: onmessage not nulled alongside the other handlers before close().

Lines 23–29 and 87–93 null onopen, onclose, and onerror but skip onmessage. This is inconsistent — while unlikely to cause real issues (the socket is being closed immediately after), nulling it keeps the pattern uniform and prevents any edge-case message delivery during the closing handshake.

Proposed fix

 if (wsRef.current) {
     wsRef.current.onopen = null;
     wsRef.current.onclose = null;
     wsRef.current.onerror = null;
+    wsRef.current.onmessage = null;
     wsRef.current.close();
     wsRef.current = null;
 }

Apply in both locations (lines 23–29 and 87–93).

Also applies to: 87-93